Mechanical positioning device for Langmuir probe

Lightweight, portable device has been developed to permit probe movement in two planes. It also provides accurate information about location of probe tip in a closed chamber

Packet loss characteristics of IPTV-like traffic on residential links

Packet loss is one of the principal threats to quality of experience for IPTV systems. However, the packet loss characteristics of the residential access networks which carry IPTV are not widely understood. We present packet level measurements of streaming IPTV-like traffic over four residential access links, and describe the extent and nature of packet loss we encountered. We discuss the likely impact of these losses for IPTV traffic, and outline steps which can ameliorate this

Extinction for two parabolic stochastic PDE's on the lattice

It is well known that, starting with finite mass, the super-Brownian motion dies out in finite time. The goal of this article is to show that with some additional work, one can prove finite time die-out for two types of systems of stochastic differential equations on the lattice Z^d. Our first system involves the heat equation on the lattice Z^d, with a nonlinear noise term u(t,x)^gamma dB_x(t), with 1/2 <= gamma < 1. The B_x are independent Brownian motions. When gamma = 1/2, the measure which puts mass u(t,x) at x is a super-random walk and it is well-known that the process becomes extinct in finite time a.s. Finite-time extinction is known to be a.s. false if gamma = 1. For 1/2 < gamma < 1, we show finite-time die-out by breaking up the solution into pieces, and showing that each piece dies in finite time. Our second example involves the mutually catalytic branching system of stochastic differential equations on Z^d, which was first studied by Dawson and Perkins. Roughly speaking, this process consists of 2 superprocesses with the continuous time simple random walk as the underlying spatial motion. Furthermore, each process stimulates branching and dying in the other process. By using a somewhat different argument, we show that, depending on the initial conditions, finite time extinction of one type may occur with probability 0, or with probability arbitrarily close to 1

Options for Securing RTP Sessions

The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism

Securing the RTP framework: why RTP does not mandate a single media security solution

This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture

Duplicating RTP streams

Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rule

Multimedia congestion control: circuit breakers for unicast RTP sessions

The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms

An experimental study of client-side Spotify peering behaviour

Spotify is a popular music-streaming service which has seen widespread use across Europe. While Spotify’s server-side behaviour has previously been studied, little is known about the client-side behaviour. In this paper, we describe an experimental study where we collect packet headers for Spotify traffic over multiple 24-hour time frames at a client host. Two distinct types of behaviour are observed, when tracks are being downloaded, and when the client is only serving requests from other peers. We also note wide variation in connection lifetimes, as seen in other studies of peer-to-peer systems. These findings are relevant for improving Spotify itself, and for the designers of other hybrid peer-to-peer and server-based distribution architectures